Honey, I Accidentally Became A Product Manager

In the past couple of months, folks asked me how I got into product management. While everyone probably wants to hear an overly romanticized story about how this was my passion from an early age, the reality is much funnier - it was an accident. I never had any plan to be in product management, and yet, this is how I built my career. This essay is a story of how I got to be in the role I am today.

The year is 2012. I am a university junior, looking for my summer internship. I’ve always aspired to build a career in software engineering - ever since the early days when I first had access to a computer, I wanted to get better at writing code and ultimately work for one of the big companies that make the software the world runs on.

Now, I am dead serious when I say that it’s something that I was really into since the late 90s, when I would come to my parents’ office after school with the goal to drink some tea, grab a snack, and browse programming forums. Back then, for me it was all about the power of Visual Basic 6. No other tool I knew could make graphical user interface (GUI) design as intuitive or easy to fiddle with. I even have photographic proof of my time as an incompetent novice engineer, trying to ask questions from professionals online.

To give you an idea how serious I was about actually being employed by a large company in the software engineering space, I, once again, am able to summon photographic proof, thanks to my parents taking quite a few absolutely random photos of occasions that probably didn’t warrant a photo. Nonetheless, here I am, in the same parents’ office in Eastern Europe, looking at Microsoft employment information, with another tab open to the now-defunct MSDN Magazine¹.

But I digress. Back in my college years, I was very certain that the kind of internship that I wanted to get was one where it will be possible for me to write code. The effort I put into learning the fundamentals of programming should be put to use in an area that is best suitable for that kind of skill. Given my experience with Microsoft folks², I went ahead and started looking for internships at the same company.

I vividly recall that there were three options that I could choose from: software development engineer (SDE), software development engineer in test (SDET, which is no longer a role at Microsoft), and program manager (PM). Thanks to the magic of the Internet Archive, I was able to travel back in time and look at the exact page that led me to make my career decision.

On that page, SDE was the primary focus - it was the role to be in if one wanted to create software, but the PM role sounded just as intriguing, even though less emphasized. Up until that point, I never actually formally researched what the role itself entailed, and my mouse cursor was already hovering over the SDE link. Naturally, I clicked on the PM link instead, and started reading the description:

[…] you drive the technical vision, design and implementation of next-generation software solutions. You predict and research how software is used and work closely with Software Development Engineers (SDEs) and Software Development Engineers in Test (SDETs) to ensure our end products exceed those expectations.

You gather customer requirements, write functional specifications and analyze usage cases to represent customers’ needs throughout the development process. You’ll invest your time in partnering with other product teams across Microsoft to drive collaborative solutions. If you love negotiating, evangelizing and empathizing on behalf of our customers, the PM role is for you.

When I was done reading it, the first thought that popped into my mind was “Well, I haven’t really taken any product management courses in college. Should I have?” The breadth of skills that were needed were kind of aligned with what I knew the basics of, but I also had no idea how to “negotiate and evangelize.” How would I even go about gaining any experience like this as a junior in college? Thinking back, one is likely to have at least a few opportunities for growing those skills during their higher education years, such as joining student organizations (which I did later) or participating in student government, among other things. That did not negate the fact that the path to expertise here was pretty opaque for someone that had no idea what it takes to be a good program/product manager.

And while we are talking about product management - you already noticed that at Microsoft this role is called “Program Manager.” You will see semantics of the title change from company to company, but the core competencies will remain the same. There are also variations of the PM role, such as Technical Program Manager (TPM), and Product Manager - Technical (PM-T), but that is a story for another article.

Before you knew it, I was sending my resume for the role. A couple of days later, I got confirmation that Microsoft was interested in talking to me - the next step was the phone informational. I briefly chatted with my friend Clint³ - he was super-helpful in outlining some hypothetical scenarios that I needed to prepare for in the interview. All of them revolved around determining my way of thinking. As it turns out, when I was applying for the PM internship, the most important thing that the interviewer was looking at was not my earlier experience, but rather the approach that I am taking to problem solving. I tried to walk through some product management “riddles” that I found online, but come phone interview time, they all flew out of the window.

“So, imagine that you are designing an appliance. What would be the information you would need to be able to determine what to build?” was the first question that I got asked. This was nothing like the riddles that I was preparing myself to answer. I tried to walk through the process and mentioned that I would first do some market research, and try to understand what are the existing market needs. The interviewer and I discussed the ins and outs of how I would go about finding the right customers to talk to, what to do if customers are asking for something that my company was not best suited for, and what would be the steps to start implementing the project. My “zero experience in product management” answers were good enough, so I was moved to the next stage - a couple of days later, I got an email letting me know that I am invited to an on-site interview. Sure enough, a couple of weeks later I was taking a cab from a hotel in Bellevue to the main Redmond campus.

Upon arrival, my recruiting contact handed me the information sheet for the day. Nice! Up until that point, I did not know what team I will be interviewing for. Looking at the sheet, it said WPD, which was Windows Phone Division. That was exciting to me, because at the time I was a Windows Phone Development MVP, and the platform was near and dear to my heart. “I can hit this out of the ballpark,” I thought. I knew so much about Windows Phone, and I was comfortable both discussing the nice and not-so-nice things about the platform, and code around those. In hindsight, I probably wasn’t as much of an expert as I assumed I would be, but the confidence was there nonetheless.

I step into the building, and the first thing I see on walls around me is a bunch of different Microsoft Office posters. An odd choice for a Windows Phone building, but maybe these folks are just passionate about Office? As I step into the office with my first interviewer, they introduce themselves and start talking about their job. And then it hits me - they do not work on Windows Phone. They work in the Office division. This is going to be a PM interview for Office, and I am not prepared for it at all. I used Office a lot, but off top of my head I was not quite sure how things like its extensibility platform or the web stack worked. Things I wish I knew before the interview.

I am pretty sure that all the interviewers throughout that day could tell that I was nervous. The questions were a mix of behavioral, thinking big, and technical product aspects. I was so nervous, that I barely recall what I discussed during four different conversations. The one thing I do remember was that I had to whiteboard a solution to a multiplayer version of a Rubik’s cube. I jotted down how I would use XML to store and pass cube state between machines, and ensure that every player had the other cube represent the true state of their opponent’s toy. The solution needed to be designed to be resilient to network outages and potential manipulation. That was probably the only question where I felt sure that I knew what I was doing - I was used to dealing with the technical stack more so than with the human stack.

The day went well, because my last meeting was the “as appropriate” interview with the Outlook group program manager (GPM), who, and somehow I do remember this, wore cowboy boots to the office. Unlike the previous interviews, he didn’t want to ask me questions, and instead had me ask him questions about his organization, type of work the folks do, and his career path. The conversation was very laid-back, and I felt that I was finally through the hardest part of the process. Around 4PM that day, I walked back to the HR building, and discussed the day with my recruiter. “Thank you for coming, we’ll let you know of the results in a week or so.” At least it was not a no-hire on the spot, I thought.

As I walked out of the building, and was waiting for the shuttle to the hotel, my phone rang. “Hi Den, I just had a brief sync with the team, they would love to extend you an offer for a summer internship as a program manager. What do you think?” This was the moment when I realized - I will be a program manager. While I knew nothing about what it means to be a good PM, at least I had enough of a base that the team thought I was a good fit. “Uh… okay, yes, I accept the offer, thank you SO much!” I have to give a massive shout-out to David Daniels⁴ here, who helped me through the process from start to finish - he made the end-to-end journey from recruitment to hiring a breeze. David is truly an exceptional individual, that I hope to work with again in the future.

That summer, I worked on a team in the Office division, called Home, Activities, and Experiences (or HAX, for short). We were building an incubation project, and my task was to figure out how to present weather to the customer. Seems like a trivial task, but those three months as a PM intern were intense. Remember how I said I knew nothing about product management? Thankfully, I had an extremely helpful manager and mentor, who were kind enough to share resources and meet 1:1 to answer my questions. The more I worked through the PM-facing problems, the more I enjoyed the role. It was a blend of social and highly technical aspects of the industry that I did not know existed. I had to be part of customer conversations, prepare prototypes (I put my coding skills to use there), work with partner teams on making sure that we can use their API (and they could handle our scale), organize design reviews, and work with engineers to make sure that we build a good experience that reflects customer needs. I never considered myself to be too much of an extrovert, but this role was proving me wrong left and right. I felt like it was a natural fit for what I wanted to do - I can code, but I can also drive a product vision at the same time. The one thing that I did find difficult, however, was that there were almost no resources at the time that would document how to do the job right. I wish I knew the things I know now back in my first internship - I would’ve been much more effective and save myself a lot of headache.

The big shock came at the end of my internship - a week before the final review, when the decision would be made on whether I will be extended a full-time offer or not. The partner team that provided the weather API determined that we were just too big to plug into their infrastructure without additional planning and infrastructure work. We are not allowed to use their API until we flesh out a cross-team contract, and that would take another six months. You read that right - six months. All while my internship was over in a week. I don’t think I slept much that day - I kept trying to figure out where it all went wrong. Could I have planned for this better? Maybe I should have asked for a commitment in writing early on, so that the team couldn’t just back out last minute? But there was nothing I could do - the team was dead set on the fact that they are not able to provide an integration, and we should remove code that relies on their API for the time being. Despite this failure on my part, in my final review with my manager and my skip-level, I was offered a full-time position. My manager explained to me that unexpected things sometimes do happen, and when you are a product manager, you need to do everything you can to de-risk your work. That includes making sure that the teams on both sides of the isle are in constant communication, and any scale concerns are bubbled up early.

Despite the setback in my project, and the fact that it never saw the light of day, the work that I’ve done was something I enjoyed so much, that I accepted the full-time position as an incoming program manager on the Outlook team. It’s been six years since then, and I still feel like there is so much to learn in the product management space, but that’s what makes me like it so much to this day - the ability to constantly seek out unmet customer needs, discuss and iterate product designs, see features take shape in the form of desktop applications, web experiences, and services. I believe that anyone can become an excellent product manager as long as you are willing to learn and be constantly curious.